Skip to content

feat(tron-wallet-snap): remove assets migration feature-flag routing - #97

Draft
ulissesferreira wants to merge 18 commits into
WPN-1497-core-adapter-routingfrom
WPN-1497-remove-assets-migration-flag
Draft

feat(tron-wallet-snap): remove assets migration feature-flag routing#97
ulissesferreira wants to merge 18 commits into
WPN-1497-core-adapter-routingfrom
WPN-1497-remove-assets-migration-flag

Conversation

@ulissesferreira

Copy link
Copy Markdown
Contributor

Summary

  • Remove SnapsAssetsMigrationStage / remote feature-flag resolution from AssetsService and SnapAssetsAdapter
  • Always route fungible reads (getAccountAssetByID, getAccountAssetsByIDs, getAccountAssetsByScope) through Core AssetsController via AssetsProvider
  • Keep snap-owned protocol assets (energy, bandwidth, staking, lock/withdrawal, rewards) on the Snap adapter for sync, reads, and keyring events
  • Drop RemoteFeatureFlagController:getState messenger endowment and @metamask/remote-feature-flag-controller devDependency

PR chain

#90#91#92#95#96this PR

Test plan

  • yarn workspace @metamask/tron-wallet-snap run jest --no-coverage src/services/assets/AssetsService.test.ts
  • CI green (manifest shasum may need Linux CI value)

@ulissesferreira
ulissesferreira requested review from a team as code owners August 2, 2026 23:53
@ulissesferreira
ulissesferreira marked this pull request as draft August 3, 2026 09:19
ulissesferreira and others added 12 commits August 4, 2026 14:41
…rvice

Move existing assets logic into SnapAssetsAdapter and keep AssetsService as a
thin facade that always delegates to the Snap adapter. Behavior unchanged;
prepares for a later Core adapter / feature-flag routing PR.
Adapter lives one directory deeper than AssetsService; bump client,
constants, and types imports to ../../../ and ../types respectively.
Update the manifest shasum, cover AssetsService facade delegation in tests,
and use SnapAssetsAdapter.isFiat inside the adapter implementation.
Move import suppressions to SnapAssetsAdapter and align test assertions
with jest prefer-strict-equal rules.
Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Align test file formatting with lint:misc:check expectations.
Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
@ulissesferreira
ulissesferreira force-pushed the WPN-1497-core-adapter-routing branch from 1a63feb to 3dc547d Compare August 4, 2026 13:45
@ulissesferreira
ulissesferreira force-pushed the WPN-1497-remove-assets-migration-flag branch from 00b11e7 to 313552f Compare August 4, 2026 13:45
cursoragent and others added 6 commits August 4, 2026 14:50
Instantiate Core messenger via getMessenger and endow
RemoteFeatureFlagController:getState plus AssetsController read actions.
Wire RemoteFeatureFlagsProvider and AssetsProvider from
@metamask/snap-networks-utils@1.0.0. No assets migration stage
resolution or Core routing yet.
Bump devDependency to match snap-networks-utils baseline. Update
AssetsService test mocks for v13 SnapsAssetsMigrationStage enum names
and RemoteFeatureFlagController:getState return shape.

Co-authored-by: Cursor <cursoragent@cursor.com>
…vider

Adopt @metamask/snap-networks-utils AssetsProvider from day one for
account-scoped AssetsController reads (getAccountAssetByID,
getAccountAssetsByIDs, getAccountAssetsByScope) behind migration-stage
routing in AssetsService. Map controller Asset shapes to private
AssetEntity via mapControllerAsset; protocol assets remain Snap-owned
through SnapAssetsAdapter. CoreAssetsAdapter is not used.

Co-authored-by: Cursor <cursoragent@cursor.com>
After rollout, always route fungible reads through AssetsController via
AssetsProvider. Snap-owned protocol assets remain on the Snap adapter.
Remove RemoteFeatureFlagController endowment and migration stage logic.
…sProvider routing

- Slim SnapAssetsAdapter to snap-owned fetch/save/read only (fetchSnapOwnedAssetsForAccount)
- Move handler logic (metadata, conversions, market data, historical prices) into AssetsService
- Add syncSnapOwnedAssets for cron sync; AccountsService.synchronizeAssets delegates to it
- Keep PR97 fungible read routing via AssetsProvider for getAccountAssetByID/ByIDs/ByScope
- Remove public saveMany, getAll, fetchAssetsAndBalancesForAccount, hasChanged from AssetsService
- Drop unused state from AssetsService constructor in context.ts
- Port and adapt unit tests; update eslint suppressions and changelog

Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
@ulissesferreira
ulissesferreira force-pushed the WPN-1497-remove-assets-migration-flag branch from 313552f to 03454c3 Compare August 4, 2026 13:54
@ulissesferreira
ulissesferreira force-pushed the WPN-1497-core-adapter-routing branch from 3dc547d to d387059 Compare August 4, 2026 13:54
@cursor
cursor Bot force-pushed the WPN-1497-core-adapter-routing branch from d387059 to ea6cdf4 Compare August 5, 2026 10:16
jeremytsng pushed a commit that referenced this pull request Aug 5, 2026
## Explanation

This PR extends the Snap’s transaction handling by introducing a
`TransactionMapper` that classifies/massages Horizon on-chain
transactions into MetaMask keyring transaction shapes
(send/swap/change-trust/receive), while also standardizing keyring
“asset” payloads to include `unit`, `amount`, and `fungible` fields and
adding some supporting formatting utilities/constants.

**Changes:**
- Added `TransactionMapper` (+ tests + Horizon fixtures) to map Horizon
transactions into keyring transactions and to skip dust payments.
- Expanded transaction utilities with operation/transaction-type
detectors (swap/receive/change-trust/dust/status helpers).
- Standardized keyring transaction request `asset` shapes and added a
shared `removeTrailingZeros` helper (plus tests) and a dust-amount
constant.

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

## Checklist

- [ ] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [ ] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants